As has been known for a long time, Internet Protocol v. 4 (IPv4) is rather limited in terms of available address space. To address the issue, standard RFC1918 defines three networks intended for private use, namely 10.0.0.0 (Class A), 172.16.0.0 (Class B) and 192.168.0.0 (Class C). None of these private networks have been routed to the public internet. Large corporations and service providers typically have Class A network (10.0.0.0) address space to expand the address space available to them, while ADSL and cable modems commonly used in homes and small offices distribute IP addresses from private 192.168 networks. Connections to the outside world are provided by utilizing Network Address Translation (NAT) technology, wherein a NAT device located between the public and private networks acts as a bridge. Since several private networks share the same 10.0.0.0 address space, they are overlapping. Overlap has been an insignificant problem as long as these private networks have been run internally, instead of routing them to the public internet.
Overlapping of private networks becomes a problem in connection with cloud computing, or cloud-based services. For instance IaaS (Infrastructure as a Service) service providers are increasingly deploying multi-tenant computing environments used to offer services concurrently to several business clients, all of whom may use the same 10.0.0.0 address space especially in the context of Virtual Private Cloud and/or other similar technologies. In use-cases such as this, the private networks used by different tenants typically overlap.
In the following description, “orchestration” is used in its established meaning within Service Oriented Architecture (“SOA”) realm, when discussing automated workflows between data processing and communication systems. Enterprises and service providers use orchestration solutions to align business requests with the applications, data and infrastructure. The solutions are typically used to define the policies and service levels through automated workflows, provisioning, and change management. With this technology, organizations are able to create an application-aligned infrastructure that can be scaled up, down or sideways based on the needs of each application. Orchestration also provides centralized management of the resource pool, including billing, metering, and chargeback for consumption.
Allocation of IP addresses, names and other network parameters to the various servers, commonly referred to as workloads, which execute applications in orchestrated environments, has traditionally been accomplished by configuring an IP address in the servers and by adding the server's name with the corresponding IP address to a domain name server (DNS) manually, or by having such allocation performed dynamically using Dynamic Host Configuration Protocol (DHCP) and dynamic DNS. Since the IP addresses and the names of the physical servers run in traditional orchestrated computing environments have been relatively static, their SOA-based automated workflow management processes have not been extended to integrate with IP and name commissioning mechanisms. As existing orchestration solutions are expanded to cloud-based computing environments, the traditional methods used to manage IP addresses and names described above will create various problems. For instance, as cloud-based computing paradigm requires that new virtual machines are provisioned on demand, the manual IP and name assignment process associated with the prior art methods used for allocation IP resources and names in traditional orchestrated computing environments quickly become a bottleneck as far as the scalability of the entire cloud-based computing environment is concerned. In addition, although the cloud-based on-demand computing paradigm requires that the life-cycle of a virtual server instance can be anywhere from minutes to several years, DHCP servers provide a predefined and fixed lease time for the automatically assigned IP addresses, thereby making it impossible to align the IP lease times with the dynamic nature of the virtual computing environment. Furthermore, the prior art techniques make it impossible to automatically reclaim an IP address when a virtual machine is decommissioned, as even with DHCP, the decommissioning is tied to the pre-defined lease time of the IP addresses that have been issued. The prior art methods thus make it impossible to align the lease time of an IP address with the unique life-cycle of each virtual machine run within the cloud.
Limitations of DHCP are quickly revealed by attempting to use in connection with cloud computing. One of the reasons for the poor compatibility between DHCP and cloud computing is that DHCP was never designed for cloud computing or web-based integration models. For instance, DHCP operates on OSI Layer 2 (L2). In practice, a client sends a broadcast message to a local-area network (LAN). A DHCP server in that LAN captures the broadcast message, inspects the client's Medium Access Control (MAC) address, which is a unique address of the network interface adapter, and returns an IP address with other network parameters to the MAC address. After that the client configures the network parameters for itself and is able to adopt a TCP/IP connection, which operates on higher OSI layers.
In practice, the above-described methodology requires that the client and the DHCP server must be interconnected by an L2 connection. In practice, the client and the DHCP server must be connected to the same LAN network. The LAN may be comprised of multiple VLAN networks, but these must be interconnected on L2 layer. In cases where clients have overlapping 10.0.0.0 address spaces, the service provider must isolate them from one another by configuring the overlapping address spaces into distinct LAN networks. As a result, all private networks are isolated from one another, which enables IP traffic within the network on one hand and prevents clients from accessing the networks of other clients.
A consequence of the facts that, firstly, DHCP operates on L2 and, secondly, overlapping address spaces must be isolated into separate LANs, is that a single DHCP cannot logically reside in multiple LANs separately. In other words, in the case of multiple private networks, each of them must have a dedicated DHCP server.
Internet Protocol version 6 (IPv6) provides two mechanisms for dynamic IP allocations. These mechanisms are called Stateful autoconfiguration and Stateless autoconfiguration. Neither autoconfiguration mechanism solves the above-identified problems because, firstly, stateful autoconfiguration (DHCPv6) is not really any different from DHCPv4 used in IPv4 environments. This is because each time an IP resource is allocated to a virtual machine, the allocated IP resource obtains a fixed lease value, which basically means that the IP resource shall remain allocated for a predefined period of time, regardless of whether or not the allocated IP resource actually continues to be utilized by the virtual machine. Within cloud-based environments, this is undesirable, because the IP addresses should be commissioned (issued) whenever a new virtual machine goes live, and decommissioned (released) whenever that virtual machine is removed from the virtualized computing environment.
On the other hand, stateless autoconfiguration means that a client autonomously obtains an IP address on the basis of router advertisements. As far as SOA architectures and orchestration are concerned, there are two reasons why this scheme may not work. First, in environments where orchestration is used, it is a typical requirement that the IP address is obtained from a network that matches the Virtual Local Area Network (VLAN) in which a virtual machine is intended to run. In other words, the IP address has to be allocated from a specific network corresponding to the VLAN in which the virtual machine is to be deployed, instead of giving the virtual machine an arbitrary IP address that happens to be available (the latter is what stateless autoconfiguration leads to). The second reason why stateless autoconfiguration may not work in this use case is that the environments are typically multi-tenant environments where the administrator has to be able to actively monitor allocation levels of each network and determine what equipments and clients are being run in the networks. In the event that the IP addresses are obtained autonomously by the clients, there is no way to control the IP addresses which a given virtual machine will have obtained, nor will there be any transparency to this process that would allow the administrator to manage these relationships and/or track the allocation of IP allocations.